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Executive Summary 

This paper is the third in a series of tcclmical publicaticms on (he topic of voice over DSL. It is intended for network 
planners and technologists who arc respon^ble for the piannlng and design of local broadband and voice access 
netwoi&s. The paper follows previous publications diat covered the market requirements for voice over DSL, and 
discussed practfcal aspects of implementing voice over DSL netwoilcs. In this paper, the broader question of 
network evolution is ^Ijspiissed, with a focus on Softswitch technology and packet voice and their roles in the 
migratioii to a fully converged local rtetwork 
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1 □ Introduction 

The unbundHng of network elements, a key aspect of the de-iegulatioii of telecoms netwoik5 that is now taking place 
all around the world, has finally opened up the k>ca! telepiione services market to competition. Competitive service 
providers have been able to enter the market and win a substantial share, particularly for medium-sized business 
customers, those with 100 employees or more. Rccrady, packet voice solutions tiiat exploit Digital Subscriber Line 
(DSL) transmission technofpgy have dramatically impmvcd the business model for deploying voice over unbundled 
loops. Vojce-over>DSL (VoDSL) solutions are enabling con^tith^e service providers for the fii^ 
address small business and upscr^e residential customers, while incumbents plan to exploit VoDSL both as a 
defensive strategy and to address copper pair ishcHtage probkms. 

VoDSL tedmology undoubtedly provides a majcn- boost to competilion in tocai telephony n^kets by greatly 
reducing the cost of local access. But this use of packet voice within the access network has done nothing to change 
the switching infiastructuie for local telephony, which continues to be based on traditional circuit-based local 
exchange switches. The hi^ cost and large scale of this equipment is a m^r deteirent to any service provider that 
wishes to enter new markets, partxcularly in second and third tier cities. Furthemxue, service providers are Imutcd 
by the capabilities of the switch to offecing voice services and callii^ features idiat are idei^cal to those pra^vided by 
the incumbent As a result, s^vice providers are forced to compete almost solely on price, and this is unlikely to 
provide a sound basis for long-term business viability. 

A tecfanobgy known as **soilswitch** has the potential radically to change the landscape of local exdiange switching. 
Properly s^tplied in the local network environnwat, sofiswitch can deliver an irresistible combination of dramatically 
lower equipment cost together with greatly enhai»ed calling feature functionality. This paper will show how 
Softswitch will both revolutionize local telephone services, and pronaotc the graoe&l evolution of access networks 
from circuit-based to padcet-based a k^ step m the migration to en^ 

2 Local Access Today 

The local access network: today comprises transmission facilities that link customer premises equipment and 
networks to local exchange switches. Traditionally, the local access network has included a combination of analog 
local loops and drcut^based <ngital transmission fiiolities. 

2.1 Incumbent Local Access 

Customers with fewer than 12 to 1 6 lines are generally served by means of analog local loops. Where the customer 
is located within about 20,000 feet from a central office^ the tocal bops run directly from the customer premises to 
the central office. Customers located beyorid the reach ofdirectarialogoomiBctions are served by outa 
cabinets tlmt contain Digital Loop Carrier (DLQ systems. A DLC connects analog loops from customer premises to 
digital transmissum jfocilities sudi as repeatered Tl or Bl lines that link the DLCs back to the central office. 

Customers with more tiian 16 to 20 lines may be served more economically by means of direct digital transmission 
facilities into the customer premises, most often Tl or £1 lines. These facilities may be connected directly to digital 
PBXs or key systems, or they may be dropped off as analog lines by means of a conversion device known as a 
channel bank. 
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2.2 Competitive Local Access 

Access to unbundled networic elements including copper loops, and tiic ability to col locals transmissioD cqupment 
in the Coitral Offices of incumbents, have enabled competitive service providers to offer ioca] phone services using 
avariety of traditional, i.e. circtiit-based access techniques. 

For business subscribers requiring more tfian 20 lines or so, oompedtlve service provideis can lease a TI or £1 
access line from tte incumbent. These lines may run direct finom the customer premises to the competitive service 
provider's local switching end office, or they may be groomed into higher speed facilitSfesisuch as T3 or £3 lines 
using collocated muhi(dexing equipment 

Tl and £1 access lines generally do not provide a cost-effective solution for subscribers zequinng 16 lines or less. 
To date, competitive service provideis have had to serve these subscribers using an individual unbundled loop for 
each line, with DifftsU Loop Carrier (DLQ systems in collocation to concentxate the traffic onto (fig^tal fecillties for 
tzanspoit to fteir local switching end officer 

Emerging Voice-ovcr-DSL (VoDSL) solutions provide a far more economical solution for subscribers requiring 1 6 
lines or less. VoDSL leverages the high-speed transmission and packet transit of the DSL access network to 
deliver multiple lines of telephony plus high-speed data over a single unbundled loop. VoDSL has the further 
advant^e that voice and data trafiic can diarc common ATM-based local network facilhies for traffic concentration 
and backhaul to the competitive service provider's local switching end office. VoPSL can jHOvide a cost-effective 
solutim for competitive tocal access down to as few as 4 lines of telephony. 



2.3 Access Network Evolution 

Ihe cmcrg«ioe of the packet-based broadband transmission technobgies that we know collectively as DSL is 
having a profound impact on the evolution of the access network. From a pure transmission standpoint, DSL has 
been around for quite a number of years - ISDN is, technically speaking, a variety of DSL. But ISDN and other 
rdated variants of DSL such as HDSL made use of traditional time-^Hvision multiplexing techniques^ wfaidi limited 
their appeal. Ihe very rapid success of today's DSL ofibrings is based on their exclusive use of packet4»sed 
tnoi^Mit, which provides a very cost-effective solution for data applications such as Internet access. 

VoDSL leverages the economies of broadband packet transmission in the access network and enables service 
providers to deliver integrated voice and data services over a common infrastructure. Many industry observers are 
now coming to tfie conchision that the fimne of the telephony access network lies with packet voice over DSL 
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Fi^UTe 1 : VoDSL Arcliiiectif I9 for Competitfva Senrice PravKfeis 



3 The Impact of Packet Voice 

We have already identified the impact of packet voice tn the access netwoik. where the economics of levcxe^i^ 
DSL to Iranspoit voice are quite compeUiog. Now let us turn to the qucsHon of packet voice in the trunk networic. 
and the prospects for end-io-end packet voice. 

3.1 Historical Perspective 

The packet voice revolution has slowly bat steadily been gaining numiention over the last few years. The earliest 
deployments of packet voice were driven by enterprises using wide-area data networks to carry intra-cntcrprisc voice 
. trafHc as a oost-savir^ measure. The success of this approach was, however, short-lived, because long-distance 
service providers brought in diamaticalty lower prices for virtual private voice networks;, all but eliminating the cost 
advantages of packet voice on private data networks. 

Internet telephony faas been another key area of application for packet voice. The flat rate access charges for Internet 
communications offer opportunities for mty or cost savings on long distance and inCematfonal calls. However, die 
relatively poor performance of die Internet in supporting rcal-tintc voice communications has limited its success as 
an alternative to the traditional PSTN, apart from its possible use to cany fax traffic, which is largely insensitive to 
transmissLon dekQ^ 
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3.2 Outlook 

Despite the patchy success of packet voice to date, loarket interest in this area remains very high. The primary 
reason for this interest is the dramatic growth of IP trafQc relative to voice traffic ia networks all over the world. 
The bandwidth consumed by voice traffic in the PSTN is growing much more slowly than the rale at which 
bandwidth consumption is growing in the Internet If Internet trafffo continues to grow at the same rapid pace, in a 
. few years time the total volume of voice trafific worldwide will be dwarfed by the volume of l?^j^^ic, most of 
which is Internet-related. 

Growth in the volume of IP traffic is driving demand for extremely rapid advances in both transmission and packet 
switching technologies. Dense Wavelength Division Multiplexing (DWDM) techniques are squeezing multi-Gigabit 
capacities out of mdividual optical libers, while core network routers are matching this growth in transmission 
capacity with multi-Gigabit iTHiting capabilities. As a result oftfaese continuing advancesi transmission and * 
switching costs for IP traffic are falling fast It is not hard to conclude that voice transmission and switching costs 
would also fall fast if voice were carried in packet form. Since there is no comparable innovation taking place in the 
circuit-switching world, one may also conclude that voice transmission and switchmg costs will not fall anything 
like so quickly if voice sf^ on the traditionaJ circuit-switched network. This vision is driving the rapid 
developments that are now taking place m packet voice - one of which, of course, is the emergence of VoDSL 
solutions for packet voice access. 

It is tempting to conclude that, in a world dominated by IP, voice will ride almost for free oh this higb-capadty IP 
infrastructure. But the requirements for voice transport are fundamentally different to those for data, and it is 
unclear at this point how a pure IP-based solution will be able to provide guaranteed delivery of voice packet 
streams with acc^tablc cnd-to-eod transmission time on a global scale. This is a major concern to service 
providers, since it is voice traffic that continues to dominate both then- revenues and their margins. As a result, most 
of the IP traffic in these high-c^chy packet networks is actually being carried over ATM, since ATM offers 
common packet-based transport facilities for both voice and data while providing the Quality of Service (QoS) 
guarantees that are so important to voice. 

As we look forward, the economic case for applying packet-switching techniques to voice are very clear. What is 
less clear right now is which packet switching technique will be dominant in tbe voice world in tbe long leniL The 
proponents of IP-based voice may argue for die elimination of the ATM layer altogether, but until IP has 
demonstrated a clear ability to provide a scalable and economically attractive solution that protects the quality of 
voice transmissions, the safe choice for vcnce wiO continue to be ATM. 

4 CODdlilleiniges for Local Voice Senfice Provideirs 

Enterprise cu^omers and medium and large businesses enjoy the benefits of a higfily competitive market for 
telecoms services today. The volume of traffic that is generated by these customers justifies the use of dedicated 
circuits from customer premises to multiple focal and long distance networks, and die PBXs that are used by these 
customers provide call routing intelligence that directs traffic on a call-by-call basis to the most appropriate carrier. 
The telephony services puztdiased by these customers typically relate to the basic transport of voice between multiple 
.enteiprise locations and die connection of voice traffic into various public networks. 

The small business or upscale residential customer with fewer than 1 6 lines does not have the advantage of multiple 
competitive service ofTerings. The economics of access do not support direct connections from these kinds of 
customers into long distance netwoiks. They arc dierefbre dependent on a single incumbent seivice provider for 
local dial tone and for access to all other services. 
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These maricet segments generate the bulk of }»of3ts for incumbent local service providers. Service providers earn 
large amounts of revenue fiom pcr-mimite charges on local calls, ton origination and termination of long distance 
caUs, and fiom us^ of custom calling fisatures and other local services such as voicemail. And since there has been 
no effective oomp^tion in these maiket segments, tarlG^ are high relative to costs^ and oiargms are therefore very 
healAy. 

Today, all local voice service is delivered from traditional circuit-based local exchange switches, largely because no 
other solution exists. Ilus represems a rpj^or barrier to process in local voice services, for three key reasons. 

4.1 Cost of Local Exchange Switehing Solutions 

The maiket ibr loca! exchange switches is dominated by e few large players who have built big^y proOtable 
businesses serving the needs of incumbent local service providers. Local exchan^ switches from these vendors are 
optimtzed to siat end ofGces that serve many tens of thousands of lines. While the scalability of these devices is not 
in doubt, high common equipntent costs make these solutions wholly unsutted for smallo- deployments where only a 
few thousand lines are needed. An enny-leve] local exchange swildi typically costs of the order of $S miUion, an 
amount that seems certain to deter oomp^tive service providers fiom entering ai^ but the largest markets. 

Some competitive service providers have succeeded in entering second and fhnd tier maikcts with traditional local 
exchai^ switches; by instalfing a switch to serve multiple cities. The switch is logically sub-divided imo 
mult^le local exchange codes, one or more for each city, and cormected by trunking facilities to local access 
networks in each city. However, while this approach does deliv^ lower switch costs per served line, any savings 
that are made in switching hardwaiew must be set off against 6ie very substantial additional transmission costs of 
backhaulmg traffic fiom each dly to acentrai switch locadon, and then sendir^g all local call traffic bade to the city 
fiom whifdi it originated. 

If local exchange switching solutions were available at much lower entry-lcvcI cost than traditional circuit switches, 
competition in local voice service would be stimulated, and customers would benefit fiom a wider choice of service 
providers and lower tariffs. 

4 J! Lack of Service Diffierentiation 

Local exchange switches all offer broadly the same set of features for custom calling services such as call waiting, 
call forwarding, caller id, selective call blocking and so on. Most of these features have been available for a number 
of years, and the delivery of completely new features is now relatively rare. This is partly because it is so expensive 
to develop and test new features, and partly because the fealurs set available today comprises virtually every feature 
it is possiUe to imagine a subsoriber being ^le to program fiom a tBlq>hone keypad. 

Since both incumbents and competitive locd service providers are dependent today on the same linuted set of local 
exchange switch products, they are constrained to offering exactly the sannre set of services. In these circumstances, 
the only way for a comi)etitive service provider to win customers is to offer lower rales. 

Differentiation solely on price has ix>t proven to be a good Iong4enn business strategy in the teleooms business. If 
local exchange switching solutions were available on ^^lich genuinely new and attractive features could be offered, 
then service providers would have a chance to differentiale on services rather than on price. This could ofTor a much 
brigjiter outlook both for margins and for customer retention. 
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4.3 Barrier to NelhAforkRSiigration 

LocaJ exchange switches are all based on circuit switching techniques. Within the switch fabric, voice traffic is 
represented as 64 Icbps streams, while at the input and output ports of the switch, the 64 kbps streams are time- 
divisiOD multiplexed into higher-speed digital futilities. The intelligence of the switdi ifaat pcifonns call routing and 
feature processing is tightly integrated with the ctrcuit-switchtng fabric. 

As wc have seen above, the economic advantages of packet voice arc driving the evolution of both access and core 
voice netwoite away from circuit switching and towards packet As packet voice becornes widely adopted for both 
access and core networking, the traditional local exchange switch represents an island of circuit switching that 
connects tbese two packet voice netwozks. The packct-'to-cnncuit conversion that must be carried out at both input 
and omput of the local cxchaigc switdi introduces undesirable additional cost and transmission delay into the voice 
path. • ' 

If a local exchange switching solution were available that were capable of delivering local voice services and custom 
calling features directly over a packet switching infrastmcture, then unnecessary packet-to-circuit conversions could 
be avoided. This has the dual effects of reducing cost and improving quality, and moves the voice network a major 
stq> closer to the ultimate goal, which is homogeneous cod4o-end packet voice. 

5 ImltrodiLflcltoooii to Sotewottch) 

Softswitch is the generic name for a new approadi to telephony switching that has the potential to address all the 
shortcomings of traditional local exchange switdi^ identified above. In this sectbn we explaui the concept of 
softswitching, and in the following sectson we demonstrate how Softswitch sohitions can lower the cost of local 
. exchange switdiing, offer the means to create differentiated local telephony services, and ease the migration of 
ndtwoxks to support packet voice end-to-end. 

5.1 The Softswitch Concept 

By far the roost complex part of a local exchange switch is the software thai controls call processing. This software 
has to nake call routing decisions and implement the call processing logic for hundreds of custom calling features. 
Today^s local exchange switches run this software on pmpiietaiy processors that are ti^tly int^rated with the 
physical circuit switching hardware itself 

In the future, wc will want to deliver local telephony over a pure packet-based infrastructure, although the migratXMi 
path to end-to-end packet will require us to work with a hybrid network handling both packet and circuit voice for 
many years to come. But the inabilhy of existing local exchange switdics to deal directly with packet voice txaflic is 
a major barrier to packet voice migration. 

As one possible solution to this, we can imagine creating a hybrid device that can swhch voice in both packet and 
circuit fbrmatSy widi all the necessary call proces^ng software integrated into this switch. While this approach may 
help us address the question of migration, it does not necessarily lower the cost of local exchange switching or 
improve the prospect for differentiated local voice services. 

The iclecoms industry appears to have reached broad consensus that the best answer lies in separating the call 
proces^ng function from the physical switching function, arul connecting the two via a standard protocol In 
Softswitch terminology, the physical swhching function is performed by a Media Gateway, while the call processing 
logic resides in a Media Gateway Controller. 
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There aie a number of leasons why this separation of functionality is believed to be the best approach: 

• U opens the way fbr smaller and more ag^ pl^m who specialize in call processing software and m packet 
switching hardware respectively to make an impact in an industiy that has been dcmiinated by laigo, vertically 

integrated vendors. 

• It enables a common software solution for call processing to be applied in a number of different kinds of 
network, including combinations of circuit-based networks and packet voice netwoiks using multiple different 
packet voice formats and physical transports:'^ . 

• . .It alfows standatd^cd commodity computing p]a*foans» operating systems and develq[>ment environments to be 
. leveraged, bringmg ccmsxlerable economies to the development, tmplenientation and |»ocesang aspects, of 
tetes^umysoftwaze* 

• It allows a central^d intelligence in a service providers voice netw^k remotely to control switdiing devices 
. located in customer pienuses. a key requirement for the full exploitation of IP telephony in the future. 

Separation between Media Gateway (MG) and Media Gateway Controller (MGC) requires a standardized protocol 
for communication between the two, and anappmpriate standard is now eroeigmg. In the next section, we take a 
look at the evohiticm of this protocol 



5.2 Protocols for Media Gateway Control 

Ihc Softswitch concqst has been around for several years, and a number of early implemeritations exis^ some of 
which have had real operational exposure. So far, sofbwitdi solutions have only been ^Ued in core networic 
switching functions, where fht call processing toctionality is largely limited to call setup and teardown, and where 
itie complex fcaimes required for local tdephony are not ai^licable. Nevertheless* early experience in this field has 
done much to shape Ae design of the protocol tiiai MGCs will use to comnumicale widi MGs. 

l'oday*s Softswitch solutions are mosUy based on a protocol called Media Gateway Control Protocol (MGCPX which 
c\'olvcd from two earlier proposals called Single Gateway Control Protocol (SGCP) and Internet Protocol Device 
Conbol (IPDC). MGCP has been published as RFC270S, iHit its status is Informational and it is not on the standards 
' track. 
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Figure 2 : Comparison between Local Exchange Switch and Sciftswitch 

MGCP is a very IP-ccntric protocol and docs not have effective capabilities to handle other packet voice transports 
such as voice over ATM. Opctatioaal experience with MGCP also identified some practical ^rtoonuDgs, such as 
Ihc lack of an effective mctiiod fijr a Media Gateway Controller to obtain information about the capabilities of a 
Media Gateway, As a rcsuh, MGCP itself has largely been abandoned, but work continues within the Internet 
Engineering Task Force (IETF) in the Media Gateway Control (megaco) working group» on a new protocol known 
as Megaoo. The International Telecommimicalions Union (ItU) has assigned the identity H.24S to this new 
protocol, and has adopted the text of Megaoo from the IETF work. The two oiganizations are woiking together to 
finalize the Megaco specifications by the end of 2000. 
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5.3 Capabilities of Megaco 

The Megaoo ]BOtoooi provides a comprehaisivc solmion for the control of MGs. As with earlier generations of 
mecfia gateway coDtrol, Megaco is based on the principle that all call processing inteliigeDce resides in the MGC. 
The MG does not retain kn owle^ge of call sta^ it provides only the capab i lity to cross-GonDect various kinds of 
media streams imder the oontiol of the MGC, and to detect and transmit various kinds of signalii^ associated with 
those media streams. 

Megaco views the MG as a oollecticm oftenninatioxis" each of which xepcesents a certain kind of media streani. A 
termination may be a fixed physicalentity such as an anafog line oraDSO timeslot m a DS1 imer&ce, or it may be a 
logical entity such as a VoIP packet stream. Logical temunationsm^ be created and destn^ed by means of 
Megaco commands. 

Cross-connections wifhin the MG are created by means of Megaco commands that request two or more terminations 
to be placed in the same **context**. If the media streams associated with terminations that are in the same context 
are of different types (for instance, one is a DSO timeslot while the otiier is a VoIP packet stream) then the MG is 
expected to perfomi appropriate mecOa conversion between &cm. To support this, terminations have various media 
stream properties associated widi them such as the identity of tiie voice encoding tfiat is to be used. 

Terminations have other pat>perties such as a list of signaling events that ihcy are expected to notify to the MGC, and 
a list of signals that Ihey arc capable of transmitting on request from the MGC. For exan^le an analog line 
termination should be capable of notifying the MGC when it sees an off-hook or an on-hook event taking place, and 
should also be capable of aj^lying ringing on the line when requested by the MGC The events and signals that are 
associated with a spedfic type of termination ans described in a ''^^ 

Megaco b designed to be an extods&le protocol, and it includes a mechanism to permit the spedfication and 
legistralion of new packages. This extensibility overcomes a major shortcoming of earlier media gateway control 
]»otocols such as MGCP, since it addresses the r^eds of packet voice protocols other than VoIP and provides the 
means to handle countiy*specific variations of analog telephony services. 

5.4 Transport of Megaco 

The Megaco protocol is designed to be transport Independent, although the specification does include some 
appendices that describe the use of both TCP/IP and UDP/IP as transport options. Most Softswitch inq^lemenlations 
are Kkeiy to use an IP-4>ased transport for Megaoo, aldiough there may be good reasons to use a native ATM-based 
transport such as L366.1 (Segmentation and Rc-essemUy sublayer for AAL2) to support remote MGs that operate 
wHh VoATM connections. 

6 Application of Softswitch to Local Telephony 

In the prevk>us sectitm, we described the fimctional components of a Softswitch solution. Next we are gomg to look 
at the realization of sofiswitcfa-based solutions for local telei&ony. We'll start by identifying various architecture 
options for the application of soflswitch technology m local telephony. 
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6.1 Network Architecture Requirements 

A comprehensive Softswitch solution for local telephony requires us to support the following tuDds of networic 

connections: 

• Access network connections based <m traditional telq>hony technologies, including analog lines, Digital Loop 
Carrier systems, and digital circuit-based facilities connecting to customer-owned PBXs. 

. • Access network connections based on padcet voice technok^ies, such as VoDSL. 

• Trunk networic connections over digits circuit-based facilities to other end-offtce switches, into local and long 
distance tandem interocMinect switches; and into special &ciUties such as £91 1 and operalOT services tandem 
switches. 

• Trunk network oonnecdons to other Media Gateways over packet-based facilities supporting VoIP and/or 
VoATM 

Each possible combination of access and trunk network type requires a spedCc combination of Media Gateway 
c^abilities to support local telephony access. The MG functions may be located on the customer premises, in the 
service provider's network, or both. 
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Figure 3 : Networfc AfchftBCtures for SoRswltcli In Loc«l Telephony 
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Figure 3 shows five e^^ples of n^work architectures tiiat use Med^a Gatew^ (o create softswitch-based solutions 
for Local telephony, lliis diagram illustraSes five netwoik "zcHies'' fiom customer premises through access network, 
originating end ofHce, core netwoilc and teimmating end ofiHoe. In each of tiiiese examples, the temuDating end 
office is ^wn as a conventional clrctiit-4>ased local exchange switch, but it could equally well be a Media Gateway 
as shovni in the originating end oSice. Li each example* the MG that {Hovidcs dial tone and other end office 
switching functions is shown in gray. Note that for clarity's sake, the Media Gateway Controller that is associated 
with eadi Media Gateway is not shown. 

Example (1) k)oks almost exactly like today's phone network, with tfic exception that the originating end office 
function is stovm here being perfoimed by a MG. In ftis case, the MG is simply a circuit switch. Theie is nothing 
in the definition ofa MG that requires it to perform media conversion, and Megaoo is fully capable of su]3(K>rting the 
ccmtrol of a pure circuit-switching Media Gateway fiom a Media Gateway Controller. 

In example {2\ die convoitional circuit-based access n^oik is replaced by a VoDSL networic An Integrated 
Access Device (IAD) on the customer premises deliveis packet voice access. Ahbou^ flie IAD does perfonn media 
conversion between analog ports and pack^ voice streams, it is not a Media Gateway in ihe soDswitch sense, 
because it is not controlled by an external MGC. The MG in the originating end office performs media conversion 
between the packet voice access network and the circuit-based core network. 

Example (3) shows a conventional telephony access netwoik, but replaces the circuit-based core networic with 
packet voice. The MG in the originating end ofiioe pei&mis media conversion between the circuit-based access 
netwoik and ttie packet-based core. A second MG perfonns lnmk comrersion to enable the caB to lennmato in a 
conventional drcuit-based local exchange. Note that the softswitdi fimctionaUty associated with this second MG is 
far less complex than that associated with the MG in the originating end ofOce, because the trunk conversion MG 
only has to deal with call setup and teardown, not widi any of the special calling fbatures tfsat ate handled by the MG 
in the originating end office. 

Example (4) combmes the packet-based access netwoik of example (2) with the packet-based core of example (3X to 
extend iSk reach of packet voice all the w^ torn the originating customer premises to a Media Gateway that is 
located as dose as possible to the terminating end offiocL 

Example (S) moves the originating end office MG functionality out to the custon^ premises. The customer 
piemises MG is controlled by a MGC that resides in the public network. Although this architecture is siqjerftcially 
very similar to ocample (4). there are some major benefhs to this ^ypioacii whidi are covered m more detail later in 
tills paper. 

In the examples that include multiple MGs, each MG may be controlled by a separate MCQ or a wgft MGC may 
control two or more of the MGs shown. A collection of MGs that is controlled by a single MGC behaves like a 
single distributed Media Gateway. Telephony signaling protocols are used to supped the switching of calls between 
MGs that are controlled by different MGCs. Where the netwoik that connects MGs is circuit-based, then 
conventional telephony {HTOtocols such as SS7 may be used between MGCs. Where the networic is packet-based, 
new signalii^ protocols such as 11323 or Ses^on Initiation Protoo(^ (SIP) are required. 
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6.2 Media Gateway Controller Requirements 

The examples illustraled above identify two distinct categories of Media Gateways: MGs that reside either in the end 
office or on the custDmcr premises* and which deliver dial tone and support the full range of end ofUce switching 
functions: and MGs that provide trunk conversion capabilities, needing only to sxsppaTt basic call setup and 
teardown. 

MGs deployed in today's networks are all of the tnmk conversion variety. They aie primarily deployed to support 
intecoonncctKHk of circuit switches over packet tninking facitities, and provide a tandem switd) repiaoement 
function. 

MGs that deliver end ofticc switching capabilities have yet to be demonstrated ~ perhaps because the MGC 
functionality that is required to support end ofifice switching is orders of magnitude more complex than that required 
for sdinple trunk conversion. 

An **end ofRoe** or "tocal excbange** MGC must implement three layers of fbnctionality fiilly to meet lhc needs of a 
comprehensive softswitch-ltased loc^ tel^hony solution: a call agent, a set of basic calling features, and a feature 
creation environment 

6^.1 Call Agent 

Call agent is the term used to describe basic MGC functionality needed lo set 19 and tear down calls, and to 
maintain details of the state of each call. The call agent interacts with the signaling protocols that exist on either side 
of MG for the purposes of coordinating call setup and teardown. Forexaroplc; an MG that supports the conversion 
of SS7 Inter-Machine Trunks to VoIP connections requhes an MGC with a call agent thai can handle S$7 ISUP 
messages and the H.245 call control messages that support VoIP call establishment as part of the H.323 protocol 
suite. 

Media Gateways that support only trunk conversion need little more than basic call agent functionality in the MGC, 
and most of today's softswrtch solutions comprise just such a call agent and little else. In a softswitch-based 
sohition for local telephony, the call agent is the lowest of three layers of fimctionality. 

The calf agent includes call routing functionality. In general, call routing ts more complex in a local exchange 
switch than it is in a tandem switch in the core of tfie netwoik. This is because the local exchange switch has to 
suppott special call routing capabilities including operaior services routing, £91 1 call routing, 800 number 
Handation, Local Number Portability G^P)> Preferred Iirterexchai^ Carrier (PIC) code routing, and Carrier Access 
Code (CAC) routing. 

6.2.2 Basic Calling Features 

An MGC that contairred only call ^ent functionality could provide local telephony service to customers that use 
PBXs. This is because PBXs deliver the calling features required by the end user» and the connection finom the PBX 
into the public netwodc requires only basic transport services, which can be provided by a call agent 

Small business and residential customers do not, generally, have their ov^ PBXs. They expect a set of calling 
features such as caller ID, call waiting, call forwardirig, voicemail and so on to be provided by the network. Service 
providers are making good margins on these services today, and subscribers have become dependent on them 
Therefore, diey must be provided as part of any Softswitch solution for local telephony. 
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Call WiaiSng 
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CaO Foiward Doni Answer 

CFDA Subscriber Ring Control 
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Automatic Callback 

Automatic Recall 
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Selective CaO Forwarding 
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Customer Originated Trace 
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F^uie 4 : Some Basic Local Telephony Calling Features 



6.2.3 Feature Creation Environment 



An MGC that just implemented a call agent and a set of basic calling features mig^it provide a softswitcb-based 
solution for local telephony diet ofTers comparable functionality to a traditional local exchange switch - peihaps at 
substantially lower cost - but it would not provide any means for a service provider to create differentiated services. 
This is a key lequirement for attracting and retaiDii^ customers, so an MGC for local teJej^ony services must have 
the ability for new services to be cteated and customized by the service provider. 

Today's local exchange switches do not offer any feciiitics fi>r SCTvice creation. All the switch's features are 
inq>Iemcnted in embedded software, and no public inter&ces exist at which features can be added to the switch or 
existipg features modified. 

Some spedal features can be unplemented outside iht switch using standard signaliog jntei&ces such as SS7» and 
this is the basis for the Advanced Intelligent Networic (AIN) concept But AIN has inomised more dian it has been 
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able to deliver - one of the reasons being that many desirable new features require direcl interaction with tiie call 
state machine, and ATN does not provide that capability. 

Developing new features in a traditiona] local exchange switch requiies opening up the embedded software and 
writmg code to the internal APIs of the switch. In most cunent switches, the software codebase has evolved for 
many years, and the sheer complexity of the code almost guarantees that complex interactions arc involved in any 
new feature developmenL Consequently, exhaustive regression testing is required to verify that the addition of a 
new feamre has not introduced enois into any of the rest of the features. 

If service providers are to have the opportunity to create their own new features^ an entirely new approach is 
required to the architecture of the feature processing software in ^ MGC. 

• A high level language is required to define the fimctionalzly of new features, and this language should be linked 
to graphical tools that enable new features to be designed visual^, without complex coding niles. 

« A fully object-oriented approach is required, in which basic feature primitives are implemented as objects, and 
new features can be built upon these feature primitives; taking advantage of mheritance. 

• The object model for call pnx^ssing should take account of tiie possible interactions between basic feature 
primitives, making it unnecessary to carry out extensive regression testing of any new feature that has been 
acated fioro the basic feature primitives. 

• The data that describes each subscriber* s configured features and the parameters ttsat control ifaem should be 

. accessible through an open, self-describing data exchange format thaX facilitates Web-based subscriber seif-^care. 
Extensible MaHcup Language ^XML) is ideal for this purpose. 

An MGC that takes this approach and offers an easy-to-use and robust feature creation environment places a great 
deal of power in the hands of telephony service providers. The low cost and rapid development time for new 
features means that^ for the first time, service providers can afford to cater to the specialized needs of specific market 
segments rather than falling back on the generic features that are found in every switch tod^. Just a single unique 
new feature that meets the needs of a particular group or community could attract and retain large numbers of new 
customers, without the necessity to offer large discounts as an inducement 

6.3 Integration of Softswitch Functionaiiity 

- The Media Gateway Controller functions described above can be thought of as ''layers'* In that ^e call agent, the 
basic calling features and the feature creation environment add progressively more sophisticated capabilities to the 
MGC. But these functions should not be treated as layers in the sense of a protocol stack, where each layer 
communicates wifli the one above and bebw by means of well-defined Application ProgFammiiig Interfaces (APIsX 
because this approadh imposes undcsiiable restrictions on the capabllhy of the MGC. 

The restrictions imposed by a strictly layered approach have become ^parent oyer a number of years of experience 
with ^^programmable switches^ which implemcitf an embedded call agent and which support well-defined APIs to an 
external server which implements advanced features. This type of switch is widely used for ^cial telephony 
applications such as calling card pmcessing. The limitation of the layered approach is that the call state model and 
Its interactions with the extemal feature server are fixed. A new feature that requires new kinds of call state or a new 
kmd of interaction with the call state model cannot be implemented in this environment 

The concept of separating basic call control &om advanced features has found its way into the Softswitch world. 
Many of the sofbwitch solutions diat are now being proposed consist of three elements: a Media Gateway, a Media 
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Gateway ContiDlIer that just handles basic call oontiol, and a "^feature servei^ In which fhe ^ivanced features and 
feature creation environment are suppcxted. This model suffets fiom the same inflexibility as the piogranunable 
switch, since the fixed nature of the APIs between the MGC and the feature snrver make it impossible to expioh new 
kinds of tnteracdon between features and the call state machine. 

A verdcaily Integrated approach to Media Gateway Controller functionaJhy provides a much more future-proof 
solutioa In this model, the call agent; the basic features and the feature areationem^ironnient are all njnnt^^ 
same system. This albws us to make the call state machine fully accessible to the feature creation environmeat, so 
that we rctaiD complete flexibility to create innovative new features that may require unfmseen call state 
interactions in ihe future. 

6.4 Operating Envf ronment for the MGC 

So Car, we have described Ac MGC function as a body of software without identifying what kind of platfonn it will 
be running on. One of the objectives of separating the physical switching functicNQ fiom the call pmoessing function 
is U> penn it call processing to lun on indostiy-standatd platfbnns, and leveiage low cost processing power and 
storage, and open oper^i^g system and developnicnt environment 

In practice, this means that the MGC shouMI lun on a high-availability Unix, server platform in a dual-redundant 
oonfignration. For ultimate protection, the two servcis fbat make fte dual-redundant configuration could be 
' placed in separate physics^ k>cations» so long as we ensure that there b sufiBcieDl network bandwidfls available 
• between them to support the call state replicalion that is required for complete &ub tolerance. 

An individual MGC may control a single MG or a collection of MGs» depending on its call processing capacity. 
Configurations that include multiple MGs oonUolied by a single MGC behave like a single distributed MG when 
viewed fiom the outside. 

6.5 Signaling Connections for the MGC 

MOCs that control Media Gateways connected to circuit-based or packet-based voice networics must support (he 
termination and processing of the telephony signaling protocols associated whh those networks. 

For packet-based voice rtetworks, the signaling protocols most likely to be used include R24$ (the signalii^ 
protocol that belongs to the H J23 protocol suite) and Session hiitiation Protocol (SEP), llicsc protocols ride on top 
of an IP transport, and since the MGC is likely to have an IP network connection for the tran^Mxit of Megaco, fiiis 
connection can be shared for the transport of the packet voice signaling. 

For cin:u!t-based networks, the applicable signalmg protocols indude SS7, ISDN Primary Rate Interface (PRI) 
signaling, and Channel Associated Signaling (CASX These protocols are usually transported on drciut-based 
. fadlitics. In the case ofmessqge-basedpmtoook such as SS7 and PRI, the messages ar^ 
oriented data link l^r such as LAPD (Link Access Protocol for O-channels) or SS7 MTP2 (Message Transfer Part 
2), which in turn occupies one or more DSO timeslots on a Tl &cility. CAS is a bitKniented protocol that is canied 
in the framing information on Tl ^ilities. 

The MGC function does not typically contain the physical interfaces needed to connect to and terminate these 
drcuit-based s^naling protocols. Since the MGC*5 native mode of communscation with the outside worid is IP- 
based, the obvious solution is to map each of die circuit-based signaling protocols onto an IP-tmsed transport 
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This is the purpose of SIGTRAN» a proposal being developed in the IETF for a method of carrying circuit-based 
signaling protocols over IP netwoilcs. The key component of this sohition is the Simple Control Transmission 
Protocol (SCTP), a protocol that can efficiently carry multq>le sessions of various signaling prolooois over a single 
IP connection. 

Since circuit-based signaling protocols are typically associated with and physically carried on the circuit-based 
transmission ik;ilities that temuoaie on Media Gatew^^ the obvious sohition for these protocols is to implement a 
; SIGTRAN signaling gateway as an additional Action within the MG. This signaling gateway will tenninate the 
' rower layers of the SS7 and PRT protocols, and encapsulate the appficatiiHi laryer messages for forwarding over the IP 
connectioa to (he MGC. 




Figure S : Media Gateway for PackeUo-Clrcuit Access with Integfaled Signalfng Gateway 



7 Migration Path for Packet Voice in Local Telephony 

We have described an approach to delivering local telephony services with a softswitch-based solution that can 
lower the cost of local telephony switching infrastructure^ deliver differentiaied services, and case the migration to 
end-to-end packet voice. In this section, we cxploro how today's VoDSL solutions, which offer a packet voice 
access network oonnectine to a conventional local exdiai^ switch, can provide the foundation for migrating to 
softswitch-based local tel^hony. 

7.1 VoDSL Today 

Today's solutions for VoDSL leverage the broadband access network to provide transport for multiple lines of 
telephony over a single broadband connection. These VoDSL solutions invariably consist of two elements: an 
Integrated Access Device (IAD) located in the customer premises which packetizes voice and voiceband data 
transmissions, and an Access Gateway located in the service provider's network that converts padcctized voice back 
Into a circuit-based fonnat suitable for delhrery to a local exchange sv^tch. 
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In tiusappToacb^lbere is no switching of voice traffi The first switdiing operation 

that voice tcaSic experiences wi&in the service provider's network takes place at the local exchange switdi that is 
upstream of tfie Access Gateway. Although an individual IAD may have packet connections to multiple Gateways* 
each port of an IAD must logically be tied to a specific focal exdiange switch. This fixed relationship between IAD 
ports and local exchange switch ports is essential to (be proper delivery of local telephone service, and has given rise 
to ^e term Ijoop Emulation^ to describe (his cbss of solution. 

7.2 Transformafion of the Access Gateway 

If the VoDSL Access Gateway has been designed vrith sufficient architectural flexibility^ then it should be possible 
to add suppoit to it for media gateway control viaMegaoo. In this case, the Access Gateway becomes a true Media 
Gatews^» and if it is paired up with a suitable Media Gateway Controller that supports local telephony features, then 
it should be able to deliver local telephone service over the VoDSL connectbn without tbe need for a conventional 
local exdiange switch. 

7J2A Media Gateway Supporting CiFcuit Jrunte 

This transfonn^n of an Access Gateway into a Media Gateway can be accomplished without any change to the 
padkct voice protocol that is used between Ibc IADs and the Gateway. The new capabilities offered by the Media 
Gateway are transparent to ^ IADs, whidi are unaware diat dial tone is now originating from the Media Gateway 
to which tfacy arc connected, instead of a local exchange switdi&at lies upstream of the Gateway. 

to function as a Media Gateway that siqjpcMts existing VoDSL IADs, the Gateway requires some additional ^gna] 
processing hardware resources to perform the followmg: 

• Generation of call progress tones, such as dial tone, rii^back; busy, &st busy, stutter dial tone etc 

• Generation of voiceband data tnuismission tooes such as those needed for sending Caller ID nilbrmation 
to the user, 

• Detection and collection of DTM F dial digits. 

- The Access Gateway is connected into the PSTN via circuit-based connections that sqiport an access network 
protocol such as or V52, Hie transformed Media Gateway can make use of the same physical 

inter&oes^ but these are now connected to tandem switches and aie controlled by trunking protocols such as SS7 
and PRI Ideally, 0ie Media Gateway will have the ability to terminate the physical, data link and netwoik layers 
of these signaling protocols, passing the signaling s^plication layer messages to the Media Gateway ContcoHer 
over an IP connection using a standard transport encapsulation such as SKjTRAN. 

7.2.2 Media Gateway Supporting Packet Trunks 

The Media Gateway described in the previous section supports packet voice access (such as VoDSL) with 
convenion to circuit-based trunks. This t>pe of functionality is an absolute requirement for a local telephony 
Softswitch solution, since much of the traffic that originates at an IAD will tsmtinate in the same local calling area 
on a regular POTS connection served by a conventional dbncuit-based local exchange switch. Therefore most of the 
packet trafSc an-iving at the Media Gateway on the access side will have to be handed off to a local access tandem 
switch via a circuit-switched trunk, typically an SS7 IMT (Inter-Machine Trunk). 
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It will not be long, however, before pacfcet-bascd voice tninkiiig is required in this scenario. The packet trunks may 
be used to network together multiple Media Gateways in the same local calling area to provide a kind of distributed 
local switch solution, ch* they may be used to hand off voice traffic to long distance packet voice service providers. 
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Case 1 : Phone C makes a Iocs! call with handoff to another senrfce provkler 

Case 2: Phone K makes a caO via a remote tandem gateway with handoff to another service provider 

Case 3: Phone A makes a station-to-stalion caB to Phone B 

Case 4: Phone D makes a call to Phone M wttich Is on another IAD 



F^nre 6 : Use Cases for Packet to Ciicuit Access from IADs 

In either case, the Media Gateway will need to be able to switch packet voice traffic arriving from the access side 
onto outgoing packet voice trunks. If the access network and the trunks are using the same packet voice technologyr 
for example ATM AAi2, then the Media Gatew^ acts siniply as a packet switch to move voice packets between the 
access and trunk networks. If diScrent packet voice technologies arc used on either side of the Me^n Gateway, then 
the MG will have to perform packet voice protocol conversion. This can be done without havhig to convert the 
voice back to TDM form and r^packetizc. An AAL2 voice packet can be converted to a VoIP voice packet by 
mapping tiie AAL2 packet header to an I?AJDP/RTP packet header. 
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For a VdDSL Access Gateway successfiilly to migrate to Ifais mle of packet voice switching, it must have a high 
perfonnance and fault-tolerant padEet-switching busL If the Access Gateway is designed to convert incoming packet 
voice traffic to a TDM bus» dien it wiU not be able to handle the passing through of packet voice traffic witiiout 
introdudi^ an additional cycle of de^>acketi2ation and re-packetization. This is undesirable because it adds 
substantially to transmission delay, and potentially squeezes end-to-cnd delay budgets that are already tight 

7.3 Migrating the Media Gateway to the Network Edge 

The transformation of an Access Gatew^ into a Media Gateway that we have just described brings us most of the 
advantage of die sofiswitch approach witiiout making any changes whatsoever to &e IADs that provide ttie 
customer connections into the packet access network. The combination of Media Gateway and Media Gateway 
Controller will allow service piovtdeis to deliva- local td^hoiiy services ttett leverage economic benefits of 
packi^ voice access, at a small fiacdon of the cost of a typicsd bcal exdiange switch. 

The economics associated with this kind of solution are such that CLECs can profitably serve local markets where 
they may only expect to win a few thousand lines. They will be able to attract customers by combining bundled 
voice and data services with innovative and narrowly targded new voice featines, instead of relying on deep 
discounts on voice services as tfaey did in the past 

But rheie is one fiiither optimization that may be iiscfiU for oestain types of custonoers. The solution we han^e 
described so far relies on a Media Gateway located in the service provider's nctwodc to provide dial tone, and diis 
MG acts effectively as an end ofBce switch. As a result* each IAD voice port must be permanently tied to a specific 
MG in the service provider's nctworit, since the MG iqineseu ts a single point of ownership for the line in handiiiig 
features like call waitnig and call forwardnig, 

A consequence of this is that ail traffic from a g^ven IAD port has to physically pass tfarougfi iht MG that owns it 
This is not necessarily a bad thuig; die MG provides essential media conversion functions on most calls to provide 
the hand-off to tocal and long distance drcuit-switcbed connections, and to perfonn packet voice protocol 
conversion where necessary between packet access and trunk networks, 

llicrc are three circumstances in which may be undesirable for all lAl>origina!)ed traffic to pass through the same 
MG in the service provider's networic, and we will explore diese below. But first, let*s look at a solution that de- 
couples Ihc IAD horn a fixed connection with a given service provider's MG. 

7.3.1 The IAD as Media Gateway 

The functional model we have assumed so far assumes no switching takes place in the network between the IA0 and 
the service provider's MG. Each IAD port is logically *'hard-wired" to an MG in the sen'ice provides network. 
This is necessary if dial tone is being originated in the service provider's MG» since the MG has to have exclusive 
control of the IADs ports in order successfully to handle complex fe^ures such as call waiting and call forwardmg. 

It follows that, to move aw^ from this model, we have to provide dial tone in the IAD itself. We can do this by 
moving Media Gateway functionality into the IAD, and by establishing a Megaco connection with the Media 
Gateway Controller. The MGC must stiU reside m the service provider's network, since it must connect into the SS7 
network to support calls over the PSTN» and it is not feasible for small business or rcadeotial users to have their own 
MGCs with SS7 connections. 

We have alreat^ described die additional functionality necessary to transform an Access Gateway into a Media 
Gateway. It comprises mainly signal processing hardware to perfonn tone generation and recognition, as well as 
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support for the Megaco protocol itself. By adding these capabilities to the IAD, we can transform it into a Media 
Gateway that brings end oflice switching functionality to the customer premises. 

The lAD/MG will support analog telephony user ports and a packet voice access port, Really over a DSL 
connection. Unlike the IAD we have previously described, the lAD/MC does not have a fixed association with a 
service provider* s MG. tt is free to establish packet voice connections with any device on tJ>e packet network that 
can support the same protocols. This freedom is, of coiiise» strictly under the contiol of the MGC that is in the 
service mt>vider*s network. The MGC sees all call setup activity and is able to track all calls by calling number, 
called number, time of day and duratioa With this infonnacion, the MGC can produce the call detail records that are 
necessary for billing purposes. 

Tht service provider's MGC is responsible fbr analyzing the dial digits collected by tiie lAD/MG and detennining 
how to route the call. If, say, a call is destined to terminate on another service provider's togal exchange switch in 
the same calling area, the MGC will direct the lAD/MG to establish a packet connection with the apiHopriate MG in 
the service provider's network where the pac]cet-to-circuit conversion can be performed and the call can be directed 
to the apprcfpnstc local access tandem. 

For diis model to operate successfully, it must be possible for the lAD/MG to establish packet voice connections to 
arbitrary Media Gateways on request If the packet voice access is based on VoIP, the MGC will supply the 
lAD/MG with the IP address of the ^rget MG, and instruct it to set up a VoIP session. If the packet voice access is 
based on VoATM, dien the MGC will instnict the lAD/MG to establish a Switched Virtual Circuit to die target MG, 
and provide the retevant ATM address. 

Having described a soIuti<m that dissolves the fixed relationshqi between an IAD and a service provider's MG^ let us 
now expk>re the circumstances in which this solution delivers real value. 

7.3.2 Direct Packet Voice Connections Between IADs 

A business customer may have multiple locations that are served by packet voice access, v^iere the IADs are all 
conr»ctcd to a common packet network. If there were a substantial anoount of inbMateiprise voice trafSc between 
and among these IADs, it would be more efficient for this tcafEic to travel on direct packet connections between 
IADs ratlier that via service provider MGs. 

A service provider may choose to support this kind of scenario with a virtual private voice network solution. In this 
case, the service providers MGC could be configured to handle calls among this community of lAD/MGs using, 
say, a 4-digit dial plan. The community of IADs woukl then behave like a distributed PBX. While VPN is not a 
new idea, this use of packet voice to hnplement a VPN solution under the control of a service piovider*5 MGC 
brings tfie conoqrt rig^t up-to-date. 

7.3^ Direct Packet Voice Connections to Remote Trunking Gateways 

As packet voice networking becomes ubiquitous, it should be possible for an lAD/MG to make direct packet voice 
connections with remote gateways that perhaps lie on the far side of a long distance or international packet voice 
network. If the packet voice access network and the loiig distance packet voice network are operated by different 
service providers, this may require packet voice peering agreements to be in place. The 1AD/MG and the remote 
gateway must use the same packet voice transport protocol in order to be able to interoperate in this way. Fbr this 
reason, support for multiple diCferent packet voice protocols (VoIP and VoATTSl) is desirable in the lAD/MG. 
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7.3.4 Stafion-to^fationCalteatthelAD 

Many businesses lequiie stqyport to locaj statiDn-«>-5l^on calling, and tod^ they have a choice of using local 
switdting based on a I^X or k3cy system, or netwoik switdiii^ using Centrcx-^ype services. 

PBXs and key systems can be used with padcet voice access networks, hut the access netwoik connections have to 
be configured in specific w^ays to deal with the presence of local switching. Typically, a "hunt group" is configured 
for outgoing calls and for caUs to the main switchboard or auto-attendant number, while an additional Direct Inward 
Dialmg (DID) group roust be configured to handle direct dialed incoming calls. With this setup, all the lequiied 
local caiiii^ features such as call waiting must be inq>l6n]ented in the VBX. 

Not all businesses are prepared to deal witii the cost and complexity of PBXs. The ahenoative solution has been to 
use Centrex, where the local exchange switch provides support for the 4 or 5 digit dial plan flat is used for station- 
to-station calling, as well as offering access to outside lines and direct inward dialing. 

One of the problems with Ccntrex is that all station-to-station calls physically pass thiou^ the local exchange 
switch, and therefore consume resources in the local access networic A Ceotrcx customer with 100 stations icquiies 
100 voice connecdons to the local exchange* 

. Using SI lADAMG with local switching support, a service provider could offer a kind of *^exl generation** Centrex 
service where all the call handling and feature processhig intelligence belongs in the MGC HaA is part of the service 
provider's nctworic; but local sx^otching is performed directly in the lAD/MG. The customer would gain all of the 
utility benefits of Centrex \^ile the service provider would only have to provide sufRcient access netwoik resources 
to support external calls. For example, a typical installation widi 1 00 stations mig^t need only 16 outside line 
oonnecticms. and these could be delivered via packet voice ova- a single DSL connection. 
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Case 1 : Phone C makes a local caB wtth handoff to another service provider 
Case 2: F^eK makes a call via a remote tandem gateway with hartdoff to ari^^ 
Case 3: Phone A makes a ststion-lO'Stabon call to Phone B 
Case 4: Phone D makes a can to Phone M which is on another IAD 



Rguie7:Ll8eCak&es for Packet to Circuit Access from lADmOs 



8 Conclusion 

In this paper, have described a migration path for broadband packet voice access finom a transport-only solution 
thai relics on a conventional local exchange switdi to a fully-fiedgcd switcbing and access solution that delivers 
**peckct voice dial-tone.** 

By far the most important ingredient in this migration path is the Softswitch technology tiiat forms the basis of die 
Media Gateway Controller. The Softswitch is where all the service intelligence resides for the delivery of local 
tdephoite services. A far higbca* level of capabUi^ is required for this type of Softswitch than for today's tandem 
Softswitch q)pIicatioQ5 where functionality is limited to interwotidng between PRI» SS7 and VoIP signaling. For 
local teleph(Hiy» the Softswitch needs not only to deliver a critical mass of local telephony features, but also to 
provide a featuTC creation eovinxmoent that enables seivioe providers to develop differentiated services. 

The development of a Softswitch Aat is truly capable of meeting these requirements is a mijor uiKleitaking. But for 
those who succeed in reaching this goai» an awesome prospect lies ahead: noting less than the total txansfbnnation 
of the local telephone network. 

/ 
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